RC_Channel: Aux switches to respect 'reverse' option #13172
Conversation
|
we probably should have done this when we first introduced the feature. Unfortunately if we apply this now then it could be dangerous. eg. someone may have a RC option setup for arming and the vehicle may arm when they upgrade firmware. |
|
I think this is useful to have, we could go through and set all switch reversing params to zero as part of this. It should be easy to tell switch from not switch once this is in. #8307 |
|
We also don't use the RCx_MIN/MAX or _TRIM values and a similar issue exists for the flight mode switch. My feeling at the moment is that this change, while certainly valid if we'd done it originally, will cause more problem than it will resolve if we introduce it now. |
|
As @tridge points out, there will be transition issues. @IamPete1 suggests using @rmackay9 points out we don't use the min/max/trim parameters; it's unclear to me how we would do that since AFAIK aux and mode switches have always been done on raw PWM threshold values. Would be a rather interesting documentation problem, if nothing else, if you were to attempt to apply the parameters to the mode switch! What problem are we attempting to solve here? I'm guessing some sort of non-programmable transmitter?! |
|
@peterbarker the problem is the same as one solved by having 'reverse' option for channel value, I believe. It looks like there is no way to safe handle this change, so it is easier leave it as is. |
|
we could add a bit in RC_OPTIONS which says "honor the reversed flag on switches" |
SergeyBokhantsev
force-pushed
the
RC_Channel_aux_reverse
branch
2 times, most recently
from
2a95ecf
to
4cac1d4
Compare
|
@tridge done with RC_OPTIONS |
|
@SergeyBokhantsev Thanks for updating this, sorry it has taken us so long to get to it. It would be great if you could rebase it. |
tridge
force-pushed
the
RC_Channel_aux_reverse
branch
from
4cac1d4
to
d638c7c
Compare
|
I have rebased this |
|
Ah. I just had a thought. Some options are considered "high" when they're in the middle. We should consider how that's handled when the switch is reversed. |
|
avoidance and OSD control are two examples where behaviour isn't strictly reversed by this flag. |
|
I think for OSD control it's only actual switches where this is true - the stick commands use high/low. So I think it's fine. |
|
Mid-position behavior does not change with or without the reverse. I believe this is ok. How it may be a problem? |
| @@ -358,6 +358,11 @@ class RC_Channels { | |||
| return get_singleton() != nullptr && (_options & uint32_t(Option::FPORT_PAD)); | |||
| } | |||
|
|
|||
| // should a channel reverse option affect aux switches | |||
| bool switch_reverse_allowed(void) const { | |||
| return get_singleton() != nullptr && (_options & uint32_t(Option::ALLOW_SWITCH_REV)); | |||
There was a problem hiding this comment.
i think we can remove the get_singleton() check on all these functions, it looks like it was leftover from when we needed singleton to get at _options
No description provided.